-
Notifications
You must be signed in to change notification settings - Fork 417
Update channel_reestablish
for splicing
#3886
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
👋 Thanks for assigning @TheBlueMatt as a reviewer! |
🔔 1st Reminder Hey @wpaulino! This PR has been waiting for your review. |
06c0dfc
to
f000b76
Compare
@wpaulino Ready for review now. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3886 +/- ##
==========================================
+ Coverage 88.83% 89.43% +0.59%
==========================================
Files 166 166
Lines 119259 125925 +6666
Branches 119259 125925 +6666
==========================================
+ Hits 105943 112616 +6673
+ Misses 10988 10944 -44
- Partials 2328 2365 +37 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
🔔 2nd Reminder Hey @wpaulino! This PR has been waiting for your review. |
🔔 3rd Reminder Hey @wpaulino! This PR has been waiting for your review. |
🔔 4th Reminder Hey @wpaulino! This PR has been waiting for your review. |
🔔 5th Reminder Hey @wpaulino! This PR has been waiting for your review. |
🔔 6th Reminder Hey @wpaulino! This PR has been waiting for your review. |
f000b76
to
e2ea3bf
Compare
Rebased. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may need to double check our incoming channel_ready
handling to make sure we can handle receiving one long after channel_ready
was already exchanged due to the new logic surrounding your_last_funding_locked_txid
.
@@ -10128,10 +10135,52 @@ where | |||
} | |||
} | |||
|
|||
#[cfg(splicing)] | |||
fn maybe_get_your_last_funding_locked_txid(&self, features: &InitFeatures) -> Option<Txid> { | |||
if !features.supports_splicing() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the TLVs are optional, I don't think we really need to check this and can always set them
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm.. if the implementation supports splicing but didn't set the feature bit, won't they understand the TLV?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. This method is only for an outgoing channel_reestablish
so they'll just ignore the TLV if they don't support splicing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I was overloading "supporting" here. What I meant was that the other implementation supported splicing in the sense they have code written. But for whatever reason they chose not to set the feature bit in their init message. In that sense, they might not ignore the TLV?
I guess in our implementation here we don't really do any checks around this but should always do the right thing (i.e., never send splice_locked
) since in the above scenario as we'd never have any FundingScope
where is_splice
is true.
Though, it doesn't seem like we check their feature bits when handling any splice-related messages. Do we care if they tell us they don't support splicing but send us those messages anyway? At very least it seems we should check if they support splicing before attempting to initiate a splice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we care if they tell us they don't support splicing but send us those messages anyway?
I don't think so, them sending the message implies they should support it?
At very least it seems we should check if they support splicing before attempting to initiate a splice.
Yeah we should always check they support a feature before we attempt to use it. The channel_reestablish
TLVs are a bit different as they're not a feature on their own, and are odd so they can be ignored if not supported.
👋 The first review has been submitted! Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer. |
e2ea3bf
to
69be701
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may need to double check our incoming
channel_ready
handling to make sure we can handle receiving one long afterchannel_ready
was already exchanged due to the new logic surroundingyour_last_funding_locked_txid
.
ACK. Also need to address https://github.com/lightningdevkit/rust-lightning/pull/3736/files#r2133028859.
@@ -10128,10 +10135,52 @@ where | |||
} | |||
} | |||
|
|||
#[cfg(splicing)] | |||
fn maybe_get_your_last_funding_locked_txid(&self, features: &InitFeatures) -> Option<Txid> { | |||
if !features.supports_splicing() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm.. if the implementation supports splicing but didn't set the feature bit, won't they understand the TLV?
69be701
to
f7b9785
Compare
While splicing is not yet fully supported, checking if the feature has been negotiated is needed for changes to the channel_reestablish logic.
The splicing spec extends the channel_reestablish message with two more TLVs indicating which funding txid the sender has sent/received either explicitly via splice_locked or implicitly via channel_ready. This allows peers to detect if a splice_locked was lost during disconnection and must be retransmitted. This commit updates channel_reestablish with the TLVs. Subsequent commits will implement the spec requirements.
The previous commit extended the channel_reestablish message with your_last_funding_locked_txid and my_current_funding_locked_txid for use as described there. This commit sets those fields to the funding txid most recently sent/received accordingly.
When splicing is negotiated, channel_ready must be retransmitted when your_last_funding_locked is not set. Further, the current logic for retransmitting channel_ready is only applicable when splicing is not negotiated.
The ChannelState::NegotiatingFunding assertion check in ChannelContext::get_initial_commitment_signed will fail when implementing splicing's channel_reestablish logic. In order to support it and channel establishment, enter ChannelState::FundingNegotiated prior to calling the method and update the assertion accordingly.
When ChannelContext::get_initial_commitment_signed is called for V2 channel establishment, any errors should result in closing the channel. However, in the future, when this is used for splicing it should abort instead of closing the channel. Move the error construction to the call sites in anticipation of this.
The splicing spec updates the logic pertaining to next_funding_txid when handling a channel_reestablish message. Specifically: A receiving node: - if `next_funding_txid` is set: - if `next_funding_txid` matches the latest interactive funding transaction or the current channel funding transaction: - if `next_commitment_number` is equal to the commitment number of the `commitment_signed` message it sent for this funding transaction: - MUST retransmit its `commitment_signed` for that funding transaction. - if it has already received `commitment_signed` and it should sign first, as specified in the [`tx_signatures` requirements](#the-tx_signatures-message): - MUST send its `tx_signatures` for that funding transaction. - if it has already received `tx_signatures` for that funding transaction: - MUST send its `tx_signatures` for that funding transaction. - if it also sets `next_funding_txid` in its own `channel_reestablish`, but the values don't match: - MUST send an `error` and fail the channel. - otherwise: - MUST send `tx_abort` to let the sending node know that they can forget this funding transaction. This commit updates FundedChannel::channel_reestablish accordingly. Co-authored-by: Wilmer Paulino <[email protected]> Co-authored-by: Jeffrey Czyz <[email protected]>
The splicing spec updates the logic pertaining to next_commitment_number when sending a channel_reestablish message. Specifically: The sending node: - if it has sent `commitment_signed` for an interactive transaction construction but it has not received `tx_signatures`: - MUST set `next_funding_txid` to the txid of that interactive transaction. - if it has not received `commitment_signed` for that interactive transaction: - MUST set `next_commitment_number` to the commitment number of the `commitment_signed` it sent.
The channel_reestablish protocol supports retransmitting splice_locked messages as needed. Add support for doing such when handling channel_reestablish messages.
The splicing spec updates channel_establishment logic to retransmit channel_ready or splice_locked for announced channels. Specifically: - if `my_current_funding_locked` is included: - if `announce_channel` is set for this channel: - if it has not received `announcement_signatures` for that transaction: - MUST retransmit `channel_ready` or `splice_locked` after exchanging `channel_reestablish`.
When a splice transaction is promoted (i.e., when splice_locked has been exchanged), announcement_signatures must be sent. However, if we try to send a channel_announcement before they are received, then the signatures will be incorrect. To avoid this, clear the counterparty's announcement_signatures upon promoting a FundingScope.
The channel_reestablish protocol supports retransmitting channel_ready messages as needed. Add support for doing such when handling channel_reestablish messages.
When handling a counterparties channel_reestablish, the spec dictates that a splice_locked may be implied by my_current_funding_locked. Compare that against any pending splices and handle an implicit splice_locked message when applicable.
f7b9785
to
b0291f4
Compare
Latest push adds some commits to address this. |
Looks like we have some logic below. I think the catch-all case still holds? We should only receive a rust-lightning/lightning/src/ln/channel.rs Lines 6491 to 6519 in 42085b9
|
The splicing spec extends the
channel_reestablish
message with two more TLVs indicating which funding txid the sender has sent/received either explicitly viasplice_locked
or implicitly viachannel_ready
. This allows peers to detect if asplice_locked
was lost during disconnection and must be retransmitted.To this end, the spec updates the
channel_reestablish
logic to support splicing.